fix(threads): use threads.com for the OAuth authorize URL - #1819
Open
giladresisi wants to merge 1 commit into
Open
fix(threads): use threads.com for the OAuth authorize URL#1819giladresisi wants to merge 1 commit into
giladresisi wants to merge 1 commit into
Conversation
Threads moved its website from threads.net to threads.com, and threads.net/oauth/authorize now 301-redirects to threads.com. For some users that legacy-domain redirect drops the OAuth query parameters, landing them on the Threads homepage instead of the consent screen. Pointing the authorize URL directly at threads.com skips the redirect. The graph.threads.net API endpoints are unaffected and remain supported.
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What kind of change does this PR introduce?
Bug fix
Why was this change needed?
A self-hoster reported that clicking "Add Threads" landed on the Threads homepage instead of the authorization screen. Threads migrated its website from threads.net to threads.com, and
threads.net/oauth/authorizenow returns a 301 Moved Permanently to threads.com (verified with curl and in the production network tab) — so every connect flow today goes through a cross-domain redirect on the legacy domain before reaching the real authorize endpoint. For some users that redirect drops the OAuth query parameters, so they land on the homepage and the consent screen never appears. The reporting user confirmed that replaying the exact same/oauth/authorizepath on threads.com shows the consent screen and completes the connection.Note the redirect preserves parameters for most users (the flow works in production today), which is why this wasn't caught earlier — but it is demonstrably lossy for some users, and linking directly to threads.com removes the dependency on that redirect entirely. Verified locally: with this change the browser's first request goes straight to
www.threads.com/oauth/authorizewith all parameters intact and the flow completes.This changes only the browser-facing authorize URL. The server-to-server
graph.threads.netendpoints are unchanged — Meta's API changelog (June 6, 2025) states the API is accessible on bothgraph.threads.comandgraph.threads.net.Other information:
None
Checklist: